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PACKET DATA COMMUNICATIONS 
Field of the Invention ~~ 

The present invention relates to internet packets which are communicated in 
accordance with an internet protocol to provide an internet packet data 
5 communications system. 

In some embodiments the internet packet may find application with the Ipv6 
internet protocol providing mobile Internet Protocol (IP) functions. 

More particularly, embodiments of the present invention find application in 
packet data communications systems, which include packet radio networks. In one 
10 embodiment the packet data network operates in accordance with the General Packet 
Radio Service (GPRS) standard. 
Background of the Invention 

GPRS has been developed to communicate efficiently packets of data to and 
from mobile nodes using either a 2G (for example GSM) or 3G (for example UMTS) 

15 mobile radio network. GPRS provides support for a packet-orientated service, which 
attempts to optimise network and radio resources when communicating data packets 
such as for example internet data packets. 

Generally, the GPRS network will be connected to another packet data 
telecommunications network, which may also be connected to further packet data 

20 telecommunications networks. The GPRS network includes a gateway support node 
(GGSN) which provides an interface between an external packet data communications 
network and nodes attached to the GPRS network and provides a plurality of bearers 
for communicating internet packets with the nodes. 

The Internet Protocol as developed by the Internet Engineering Task Force 

25 (IETF) has become a preferred way of communicating packet data via 
telecommunications networks. Whilst version 4 of the Internet Protocol (Ipv4) has 
been standardised and has been deployed in many fixed networks, version 6 of the 
Internet Protocol is being developed in order to provide improved facilities. Amongst 
these improved facilities is a facility to communicate data packets to and from mobile 

30 nodes, which roam from a home network to a foreign network during an IP session [1]. 
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Generally, following a process known as route optimisation which will be described 
shortly, a source and a destination address in the header of IP data packets being sent 
from and to a Mobile Node (MN) respectively will change as a result of the MN 

roaming to the foreign network. 
5 The MN may be communicating IP data packets with a Correspondent Node 

(CN) which is attached to a GPRS network, then the GGSN of the GPRS network 
must be arranged to route the IP data packets via an appropriate bearer to the CN 
(which itself may be mobile). If the MN roams to a foreign network mid-session then 
the GGSN must be arranged to route the IP data packets to the CN (mobile user 
10 equipment) via the appropriate bearer. The appropriate bearer will have been set up by 
the GGSN when a session initiation was established at a time when the MN was 
attached to its home network. As such me parameters for the bearer will have been 
established with reference a home address of the MN as the source address. However 
as explained above, the source address in the header of the IP data packets will be 
15 changed during the session from the home address of the MN, when attached to its 
home network, to a care-of-address after the MN roams to the foreign network. 

It has previously been proposed in co-pending UK patent application numbers 
0226289.7, 0222187.7, 0230336.0, 0222161.2 and 0230335.2 to provide a mobile 
node's home address in an extension header field in IPv6 known as the hop-by-hop 
20 field. As such the GGSN will be able to identify the appropriate bearer through which 
IP data packets can be routed to a correspondent node (CN) attached to me GPRS 
network, because the MN's home address provides the source address with respect to 
which the appropriate bearer was set up. However according to the Ipv6 standard, if 
the hop-by-hop filed option is selected then every router along a communications path 
25 followed by the internet data packets from an MN to the CN is required to read the 
mobile's home address in the hop-by-hop field. This requirement could represent a 
reduction in performance of a network formed by the routers, as a result of the router 
reading the mobile's home address although this address may not be relevant to the 
router. 
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Summary of Invention 

According-to the present invention there is provided- an internet— packet— 

comprising a header field, the header field including a field identifying a source 
address of the internet packet, a field identifying the destination address of the internet 
5 packet and a next header field identifying whether an extension header follows the 
header and a type of the extension header. The extension header indicates a hop-by- 
hop option header, the hop-by-hop extension header including a router alert option 
header indicating that the extension field is optional for a router to read, and a field 
providing information for a gateway support node of a packet radio system network. 
10 As explained in our co-pending UK patent application number 0226289.7, by 

providing a home address of a mobile node in the hop-by-hop extension header field, 
inter-working between a gateway support node of a packet radio network and a data 
communications network when supporting mobile IP functions can be provided. 
However, if every router in a communications path between a mobile node and a 
15 correspondent node is required to read all the data in the hop-by-hop extension header, 
then a substantial reduction in performance to a network formed by the routers may 
occur. By providing a router alert option field in the hop-by-hop extension header, a 
relatively short indication that the hop-by-hop field is providing information to a 
gateway support node is made and therefore does not need to be read by a router. As a 
20 result any loss in performance caused by a router having to read the entire hop-by-hop 
field can be substantially reduced. 

In some embodiments the internet packet is formed in accordance with the Ipv6 
specification, the routers and the packet radio network being operable to support the 
Ipv6 specification. As such, according to the Ipv6 Router Alert Option standard the 
25 first three bits of the router alert option field are set to be zero, any router which does 
not recognise this Router Alert Option type will skip the information in the hop-by-hop 
field. For some applications (explained below) the remainder of the hop-by-hop 
extension header field may include at least a 128-bit address. According to the IP Ipv6 
specification defined at www.ietf.org/rfc/rfc2460.txt [3], the hop-by-hop extension 
30 header field must be read and processed by every node along a packet's 
communication path. If a node or router is only required to read a relatively short 
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field (three bits) indicating that the rest of the message is only relevant to a gateway 
support node of a packet radio network, then a performance penalty for having to read 
the hop-by-hop extension header will be relatively small with respect to having to read 
the entire hop-by-hop field. 
5 In one example, the gateway support node establishes a packet data bearer for 

communicating internet packets from a mobile node across a packet radio network to a 
CN attached to the network in accordance with a source address of the internet packets 
when an IP session was set up. If the source address of internet packets in the basic 
Ipv6 header changes during the session as a result of the mobile node roaming to a 
10 foreign network, the gateway support node will not recognise the source address and 
will drop the internet packets. The original source address (home address) which was 
used to establish the bearer across the packet radio network, is known as the home 
address. By providing the home address in the hop-by-hop extension header the 
gateway support node will be able to identify the appropriate bearer even though the 
15 source address of the internet packet in the basic Ipv6 header will have changed to a 
care-of-address not known to the gateway support node. 

Various further aspects and features of the present invention are defined in the 
appended claims. These include a gateway support node, a router and a method of 
communicating internet packets. 
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Brief Description of the Drawings 

EmbodSments of the present invention will now be described by way of 
example only with reference to the accompanying drawings where like parts are 
5 provided with corresponding reference numerals and in which: 

Figure 1 schematically illustrates an example architecture of a mobile radio 
network which is arranged to support packet data communications; 

Figurei 2 schematically illustrates a mobile node communicating with a 
correspondent node via a home network and after roaming to a foreign network 
1 0 performing a route optimisation procedure; 

Figure 3 schematically illustrates example internet packets at different stages in 
the route optimisation procedure; 

Figure 4 provides a schematic illustration of parts of a packet radio 
communications network; 
15 Figure 5 is a schematic illustration of the parts shown in Figure 4 illustrating an 

operation of a gateway support node to communicate down-link packets to a 
correspondent node; 

Figure 6 is a schematic illustration of an internet packet which has been 
adapted to provide a router alert header as part of a hop-by-hop extension header, with 
20 a field for providing information to the GGSN of Figure 2; 

Figure 7 is a flow diagram illustrating the operation of the gateway support 
node when processing an internet packet in the form illustrated by the example shown 
in Figure 6 for a down-link communication; 

Figure 8 is a flow diagram illustrating the operation of the gateway support 
25 node when processing an internet packet in the form illustrated by the example shown 
in Figure 6 where the GGSN information field includes a source home address; 

Figure 9 is a flow diagram illustrating the operation of a router when 
processing an internet packet in the form illustrated by the example shown in Figure 6; 
Figure 10 is a schematic illustration of the parts shown in Figure 4 illustrating 
30 an operation of a gateway support node for an up-link communication; and 
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Figure 11 is a flow diagram illustrating the operation of the gateway support 
n0 de when processing internet packet in fee form illustrated by me example shown 
in Figure 6 for an up-link communication. 
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Description of the Preferred Embodiments 

Mobile Packet Radio Network Architecture 

An example architecture of a packet radio network which is arranged to 
support packet data communications is provided in Figure 1 and explained in more 
detail in Annex 1 . To assist in understanding and explaining the embodiments of the 
present invention and the advantages provided by such embodiments, a brief 
description will be provided here. The packet radio network presented in Figure 1 
illustrates an arrangement which conforms to the GPRS/UMTS standard and provides 
a packet radio network for communicating internet data packets with nodes which are 
attached to the network via terrestrial radio bearers referred to as UTRAN. The packet 
radio network includes a Gateway GPRS Support Node (GGSN) which is operable to 
provide an interface between an external network PDN and the nodes attached to the 
GPRS/UMTS network. Since the nodes are communicating via the UTRAN radio 
interface they may be generally mobile nodes. However in the following description 
the mobile user equipment (UE) which are attached to the packet radio network will be 
referred to as correspondent nodes CN. As will be explained shortly, the 
GPRS/UMTS network provides a plurality of packet data bearers for communicating 
internet packets from the GGSN to the correspondent nodes CN and from the 
correspondent nodes CN to the GGSN. Typically, packets received from 
correspondent nodes by the GGSN are allowed to egress from the packet radio 
network to the external packet communications network PDN. These packets may be 
destined for other nodes which may be attached to the external network PDN or may 
be attached other networks, the packets reaching these nodes via the external network 
PDN. 

Mobile Ipv6 Route Optimisation 

Route optimisation is a known as part of the internet protocol mobility standard 
version 6 (MIPV6) and may be performed for a node which roams from a home 
network to a foreign network. The route optimisation is a process by which a node, 
which changes its affiliation from a home network to a foreign network, can be 
arranged to communicate internet packets to and from the node via the foreign network 
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without being routed via the home network and without requiring a home agent as is 
the case for Ipv4. A' node which changes its affiliation by roaming from its home 
network to a foreign network will be referred to in the following description as a 
mobile node. 

5 As is conventional with the internet protocol, nodes which communicate 

internet packets between each other provide the destination address as well as the 
source address in the basic internet packet header. Figure 2 provides an illustration of 
a route optimisation process between a correspondent node CN attached to a GPRS 
network and a mobile node MN. In Figure 2 the correspondent node CN is 
10 communicating internet packets to and from the mobile node MN whilst the 
correspondent network MN is affiliated with a GPRS/UMTS network 200. As 
illustrated by two positions of the mobile node MN 202, 204, the mobile node which 
was originally communicating internet packets with the correspondent network CN via 
its home network 210 moves to a foreign network 212. Thus originally the mobile 
15 node MN was communicating internet packets via its home agent HA. When the 
mobile node MN moves from the home network 210 at position 202 to a foreign 
network 212 at position 204 internet packets according to a conventional operation of 
Ipv4 would have to be routed via the home agent. That is to say the destination 
address for packets sent to the mobile node MN would be its home address, and the 
20 source address of packets sent from the mobile node MN would be its home address. 
As such, internet packets would have to be routed via the foreign network 212 and the 
home network 210 to and from the correspondent node CN via the GPRS/UMTS 
network 200. It will be appreciated that routing packets via the home agent after the 
mobile node MN has roamed to the foreign network consumes network resources 
25 unnecessarily and further increases the delay in communication of the internet packets. 

As mentioned above, route optimisation is a process by which internet packets 
are communicated between the correspondent node CN and the mobile node MN 
without having to pass through the home agent HA thereby reducing the resources 
used to communicate the internet packets. Typically a delay in communicating 
30 packets is also reduced. 

Figures 2 and 3 effectively provide a summary of relevant parts of the route 
optimisation process, which will be useful in understanding the embodiments t>f the 
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present invention, which will be described shortly. Figure 3 provides an example 
illustration of Internet packet headers before and after route optimisation. In Figure 3 
internet packet 300 provides an illustration of an internet packet (Ipv6) header to be 
sent from the mobile node MN when attached to the home network at position 202 to 
5 the correspondent node CN when attached to the GPRS network 200. The Internet 
packet header 300 includes the address of the correspondent node CN within a 
destination field 302 and the home address of the mobile node (MN) within a source 
address field 304. The Internet packet header 300 also includes a further field known 
as the hop-by-hop field 306 which will be explained shortly. The IP packet 300 for 

10 communication from the mobile node (MN) to the correspondent node (CN) is known 
as a down-link internet packet. 

For the up-link, that is to say from the correspondent node CN to the mobile 
node MN, an Internet packet header 310 is shown to include within the destination 
field 312 the home address of the mobile node MN and, within the source address field 

15 3 1 4, the address of the correspondent node CN. 

Following route optimisation in accordance with a change of affiliation of the 
mobile node, the mobile node MN must inform the correspondent node of its new 
address. The new address, that is the address to be used to access the mobile node MN 
via the foreign network, is known as the care-of-address. To inform the correspondent 

20 node CN of the care-of-address of the mobile node MN, the mobile node MN sends 
the correspondent node CN a binding update message. 

Following the binding update the internet packet header for the down-link 350 
now includes the care-of-address of the mobile node MN in the source field 352. 
Correspondingly, the destination field, of the internet packet sent to the mobile node 

25 MN contains the care-of-address of the mobile node in the internet packet header 360. 

Should the CN itself change its affiliation either within the network or to a 
foreign network then correspondingly a binding update would be performed by the 
correspondent node CN. As illustrated in Figure 2 the cache address store of the 
mobile node 230 is then updated to include the care-of-address of the correspondent 

30 node CN in association with the address of the correspondent node CN with the effect 
that subsequent Internet packets use the care-of-address of the correspondent node CN 
in place of the home address of the correspondent node. 
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Functions of the GGSN 

An example embodiment of tbe present invention will now be described with 
reference to Figure 4 which provides elements forming part of the GPRS/UMTS 

5 network which appears in Figure 2. In Figure 4 a gateway support node (GGSN) 400 
is shown together with a Serving GPRS Support Node (SGSN) 402 and a Universal 
Terrestrial Radio Access Network part (UTRAN) 404. The GGSN 400, the SGSN 402 
and the UTRAN 404 form part of the packet radio network as represented in Figure 1 
for communicating data packets to and from mobile User Equipment (UE) 406, which 

10 for the illustrative explanation forms the correspondent node CN. The UTRAN 404 
includes RNCs and Node Bs as represented in Figure 1 and provides a facility for 
communicating packets via a radio access interface formed by the Node B with the UE 
406. 

As will be appreciated in the up-link direction, that is from the correspondent 
15 node CN 406 to the GGSN, corresponding tunnelling is employed to route the Internet 
packets back to the GGSN so that the internet packet can egress from the 
GPRS/UMTS network 200 to the foreign network 212. As shown in Figure 2 a 
communication path from the MN to the GGSN 400 includes several routers 420, 422, 
426 within the foreign network 212. 
20 Also included within the GPRS/UMTS elements shown in Figure 4 in the 

GGSN 400 is a Traffic Flow Template (TFT) controller 470 and a Service Based 
Policy (SBLP) controller 472. The TFT 470 and the SBLP 472 operate in accordance 
with an embodiment of the present invention as will be described shortly to manage 
the communication of IP data packets from the GGSN to the mobile UE (CN) and 
25 from the mobile UE (CN) to the GGSN and outward to the foreign network 212. 

In the following description the mobile UE 406 forms the correspondent node 
CN as represented in Figure 2, whereas a node from which the UE 406 receives 
internet data packets and sends internet data packets to forms a mobile node which 
roams to the foreign network 212 as explained with reference to Figure 2. 



P017878GB 



11 



In order to provide an explanation of the embodiments of the present invention 
the operation of the TFT cpnfroller 470 _which is shown in Figure 4 will be briefly 
described with reference to Figure 5. 

Traffic Flow Template (TFT based packet filte ring at the GGSN) 

As shown in Figure 5 the TFT controller 500 which operates in the GGSN 
mobile IP layer is provided with a list of source addresses 502 which are used to 
control the communication of IP data packets in accordance with a source address 
included within the Internet packet header. The TFT 500 arranges to communicate the 
IP data packets via an appropriate bearer which has been set up using the packet data 
protocol context activation which may be initiated by an application in the UE (CN), 
or on the mobile node MN and is analogous to logging onto a required destination. 

To select an appropriate UMTS bearer the GGSN to establish a traffic flow 
template in accordance with the following parameters: 

• IPV4 source address type 

• IPV6 source address type 

• Protocol identifier/next header type 

• Single destination port type 

• Destination port range type 

• Single source port type 

• Source port range type 

• Security perimeter index type 

• Type of service/Traffic class type 

• Flow level type 

For each PDP context to be used for a multimedia session a traffic flow 
template is generated by the mobile terminal and sent to the GGSN which 
subsequently uses this traffic flow template to filter incoming packets based on 
information provided in the template. For example, for packets sent from an Ipv6 
mobile node, the correspondent node CN will create a traffic flow template which 
creates the IP address of the mobile node as the Ipv6 source address for packets in the 
down-link direction. 




10 
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As shown in Figure 5 an internet packet 504 received from the external packet 
data communications network 212 on Ihe down-link, for communication to the CN 406 
may include the address of the correspondent node CN ADD in the destination address 
field 506. The internet packet may include the home address of the mobile node HA 
of MN in the source address field 508. 

In operation the TFT controller 500 checks the source address of the internet 
packet against the fist 502 and routes the internet packet via the appropriate data bearer 
which has been set up within the TFT controller for communicating the Internet packet 
to the respective correspondent node CN. However, what happens when the mobile 
network roams from its home network 210 to the foreign network 212 as shown in 
Figure 2? 

, As explained with reference to Figure 3, following route optimisation the 
source address for the mobile node will be the care-of-address of the mobile node. 
Thus, an Internet packet 5 1 0 corresponding to the Internet packet 504 will be sent from 
15 the mobile node to the GGSN for communication to the correspondent node CN 406. 
As shown the IP header 510 received from the mobile node MN when attached to the 
foreign network 212 includes within its destination address field 512 the home address 
of the correspondent node CN ADD, but within its source address field 514 the care- 
of-address of the mobile node C of A MN. The TFT has a packet bearer, which has 
20 been set up and defined for conveying the internet packets to correspondent nodes in 
respect of the source address. However, the internet packet 510 received from the 
mobile node after it has roamed to the foreign network 212 will not be recognised by 
the TFT controller 500 and so the packet will be dropped, unless some adaptation of 
the GGSN is provided. 
25 Use of the Hop-bv-HoP E xtension Header Field 

A previously proposed solution disclosed in [5] for addressing the inter- 
working between the TFT controller 500 in the GGSN after route optimisation is to 
include the home address of the mobile node MN within an extension header field 
known as the hop-by-hop field 516. By including the home address of the mobile 
30 node wilhin the hop-by-hop field 516, the TFT controller can identify the appropriate 
bearer, which should be used to convey an Internet packet to the correspondent node 
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CN. This is the packet bearer, which was set up during a PDP context activation as 
part of a session initiation. Thus, if the mobile node roams to a foreign network during 
mid-session then by providing the home address of the mobile node in the hop-by-hop 
field the TFT controller 500 can identify the appropriate bearer to be used to convey 
5 the internet packets to the CN 406. The hop-by-hop address field is also known as the 
routing header type two (extension to header of IP6 packets). 

According to the Ipv6 specification [3], the hop-by-hop extension field must be 
read by each intermediate router. As such, using the hop-by-hop extension header to 
provide the mobile's home address, will require that each router along a path 
10 communicating the internet packets from the mobile node to the correspondent node is 
required to read the mobile's home address in the hop-by-hop extension header. This 
requirement could represent a substantial performance degradation of the IP network, 
resulting from the requirement to read the mobile's home address in the hop-by-hop 
extension header. 
15 Use of Router Alert Option for GGSN Information 

In order to reduce a degradation in performance resulting from all routers along 
the communications path having to read the mobile node's home address in the hop- 
by-hop extension header field, an internet packet according to an embodiment of the 
invention includes information relating to supporting Ipv6 mobility for the GGSN, 

20 such as for example a router alert option in the hop-by-hop extension header which 
includes the mobile node's home address. A header for the internet packet is 
illustrated in Figure 6. 

In Figure 6, the fields "Version" 601, "Traffic Class" 602, "Flow Label" 604, 
"Payload Length" 606 and "Hop Limit" 608 are as specified in [3] and so will not be 

25 explained here, since the reader can refer to [3] for this information. The "Next 
Header" field 610 is arranged to specify that the next header to the present header 
provides a hop-by-hop option (with a value = 0) and so must be read. . The "source 
address" field 612 and the "destination address" field 614, provide the source and 
destinations addresses as explained with reference to Figure 3. 

30 The "Next Header" field 616 within the hop-by-hop extension header part 618 

provides an indication as to whether or not a further header follows the current 
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extension header. The field "Header Extension Length" 620 provides an indication of 
the length of the extended header if present 

The next fields in the IP packet are specified in accordance with the router alert 
option type [4]. Tfa. first of these fields provides Are "Renter Alert Option" field 622. 
5 The •'Router Alert Option" field provides an indication that the field is for alerting 
outers and has a valne of zero specified as three bite (000). The next field 624 
provides a "hop-by-hop option type" which is set to a valne of five by a field length of 

five bits. . - 

The next field 624 provides a valne field and is set to a valne to tndtcate that 

,0 the information in the remainder of the header is provided for the GGSN of a GPRS 
network. This valne may be any value which has not so far been reserved m the 
specification [4]. For example the value may be "3". Alternatively, it may be possible 
,„ utilise a valne already reserved such as "2" meaning "Datagram contains an active 
neW ork message". If the definition of the value "2" permits the use of mis value for 

15 mobility information for the GGSN, then mis value may be re-used. Otherwtse the 
next available valne which is "3" wiU be used. The remaining field 628 provides the 

information to the GGSN. 

One example of the information for the GGSN whieh may he provided m the 
field 626 is the mohile node's home address. This provides a 128-bit address field. 
20 The router alert field in contrast is only 3 -hits with the «hop-by-hop option type" field 
being only 5-bits. As a result, since every router along the communications path must 
only read 3-bits to determine whether the information is relevant to the router 
concerned, a performance loss is substantially reduced with respect to a performance 
loss which may have occurred if a remaining 128-bit address field was also requnred to 
25 be read by every router along the communications path. 
Summary of ti»» Oneration " f + h » GGSN for TFT 

In summary, by analysing the hop-by-hop field in combination with the source 
address field the TFT controller 500 can identify the appropriate bearer 520 to 
• communicate the Internet packets to the correspondent node CN because the hst 502 
30 includes the home address of the mobile node. The operation of the GGSN when 
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receiving IP packets for ingress to the packet radio network is summarised by the flow 
diagram of Figure 7 and explained as follows: 

SI: An internet packet according to the example in Figure 6 is received 
from the external network. 
5 S2: The GGSN detects whether a next header field of fee internet packet 

includes a hop-by-hop field option. If the GGSN does detect that the next header field 
includes a hop-by-hop field option, then processing proceeds to step S3, and otherwise 
continues from step S6. 

S3: If the GGSN detects the hop-by-hop extension header then at step S3 
10 the GGSN identifies whether a router alert header type is present, within the hop-by- 
hop extension header field. In some embodiments this step may be omitted. 

S4: In step S4, the GGSN recovers information from the field provided in 
the hop-by-hop extension header field providing data representing the information. 

S5: The GGSN then controls egress and/or ingress of internet packets to the 
1 5 packet radio network in accordance with the information recovered. 

S6: At step S6 the GGSN continues processing with oither functions, the 
processing of the current packet may however continue depending on the content of 
the GGSN information field. 

As will be appreciated one of the uses of the field in the hop-by-hop extension 
20 header field is to provide a mobile node's home address as source address, so that the 
TFT can identify the appropriate bearer for communicating the internet packet to the 
correspondent node. For this example embodiment the GGSN operates as represented 
by the flow diagram in Figure 8 and explained as follows: 

S7: The GGSN detects, from either the data provided in the hop-by-hop 
25 extension header field for the gateway support node, or the source address of the 
internet packet, a source home address of a mobile node communicating the internet 
packets. 

S8: The GGSN determines whether the source address of the internet 
packet identifies the packet data bearer for communicating the internet packets to a 
30 correspondent node attached to the packet radio network. If the source address does 
correspond to a packet data bearer then processing proceeds to step S10, otherwise 
processing proceeds to step S9. 
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S9- The GGSN determines whether the home address provided in the 
GGSN information field identifies me packet data bearer for communicating ^ 
internet packets to a correspondent node attached to the packet radio network. If *e 
home address does correspond to a packet data bearer then processing proceeds to step 
5 S10,otherwiseatstepSllthepacketisdropped. 

S10: The GGSN allows ingress of the internet packets via the identified 

packet data bearer, or 

Sll: The GGSN drops the internet packet. 

Summary. of Router Operation 

10 As will be appreciated, routers along a eommurueations path between the 

nmhile node and the corespondent node may now operate according to the standard, 
wimoutbeingrenuiren^readflteennrehop-by-hop extension header. Thistsbecaw* 
the route only needs to read as far as the route alert option field an rguore the 
remainder to the hop-by-hop extension header. 

in summary, a route may handle the internet packet according to Frgure 6 as 
summarised in Figure 9 and explained as follows: 

S20: The router receives fire internet packet m accordance with the example 

illustrated in Figure 6. 

S22- The route detects whether or not a next header field of me tntemet 
20 packetmcludesahop-by-hopneldoption. Ifno. men * step S28, me route processes 
the internet packet as usual based on the source and destination addresses m me un- 

extended header. m 

S24- If the router detects that the hop-by-hop extension header is present, 
then the router determines whether a router alert header type is present within the hop- 
25 by-hop extension header field, by reading the router alert field (3-bits according to 
I P v6 [4]). If the router alert header is present then processing proceeds to step S28 and 
the router does not read Ihe extension header field. 

S26: If the router alert header is not detected then, the hop-by-hop extension 
header is read by the router and processes the header accordingly. 
30 S28- If the router alert header is detected or there is no hop-by-hop extension 

header field present, then the router forwards the internet packet in accordance with 
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the destination address and does not read further the content of the hop-by-hop 
extension field. 

S30: Processing of internet packets by the router continues. 
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Figure 10 provides a simplified diagram of parts of the GPRS/UMTS network 
shown in Figure 4 and configured for communicating data packets on the up-link from 
5 the correspondent node CN to the mobile node MN as previously discussed with 
reference to Figure 5 for down-link communications. 

In Figure 10 a bearer 900 which was initiated by the correspondent node CN 
using a PDP context activation is provided for up-link communications to the mobile 
node MN. An example of an Internet packet header 902 communicated with an 
10 Internet packet on the up-link is sent using me bearer 900 through the UTRAN 404, 
the SGSN 402 to the GGSN 400 and outward to the foreign network 212. However, 
within the GGSN 400, the SBLP is provided in order to police access by the CN 
(mobile user equipment) to the quality of service resources in the UMTS network and 
further out into the external packet data communications network 212. The SBLP 472 
15 operates to effect a policy function as a policy decision point or policy enforcement 
point in order to prevent theft of service attacks by unscrupulous parties. For example, 
an unscrupulous party may wish to gain access to IP multimedia subsystem services 
(IMS) even though the party has not subscribed to the services. As such, unless the 
GGSN can recognise a legitimate destination address, then the packet will be dropped. 
20 The destination address is a legitimate address established when the IP session was set 
up. For the mobile node, this will be the home address. 

By using the internet packet according to the example shown in Figure 6 for 
up-link communications, in which the destination mobile's home address is provided 
in the hop-by-hop extension header, the internet packet will be allowed to egress from 
25 the GGSN in accordance with the SBLP function. Again, by providing the home 
address as part of a router alert option header, a potential performance penalty which 
may result for routers within the network having to read the hop-by-hop field may be 
reduced. 

The operation of the GGSN in accordance with an egress of packets from the 
30 GPRS network is illustrated in Figure 1 1 and summarised as follows: 
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S30: The GGSN perform egress packet filtering in accordance with a 
destination address of internet packets received from the plurality of packet data 
bearers. Egress of internet packets is allowed for internet packets having a legitimate 
destination address in accordance with a Service Based Local Policy (SBLP) function. 

S32: Upon receipt of the internet packet illustrated in Figure 6, the GGSN 
detects from the data provided in the hop-by-hop extension header field for the 
gateway support node a destination home address of a mobile correspondent node 
which is to be the destination of the internet packets. 

S34: If the hop-by-hop extension header field contains a legitimate destination 
home address, then at step S35 egress of internet packets is allowed. Otherwise at step 
S36 the internet packet is dropped. 

Various further aspects and features of the present invention are defined in the 
appended claims. Various modifications can be made to the embodiments herein 
described without departing from the scope of the present invention. 
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ANNEX 1 

GPRS/UMTS Architecture V ~ 

The terminology and architecture used in Figure 1 corresponds to that used for 
the UMTS and that proposed for 3G as administered by the 3GPP, more details for 
which may be found in [1]. In Figure 1, a Gateway GPRS Support Node (GGSN) is 
connected to an external Packet Data Network 102, (PDN). The external PDN 
communicates as packets using the Internet Protocol (IP). An interface 104 between 
the GGSN and the external network is labelled Gi which has been standardised 
although further aspects are being standardised. Also connected to the GGSN is a 
Serving GPRS Support Node (SGSN) 106 via an interface 108 labelled as Gn/Gp 
which is also being standardised. 

The GGSN and the SGSN are two of network components, which are required 
to support GPRS. The GGSN acts as the gateway between the external packet data 
networks (PDN) and the mobile network, which supports GPRS. The GGSN contains 
sufficient information to route incoming IP data packets to the SGSN that is serving a 
particular User Equipment (UE) which is mobile and receives data via a radio access 
facility provided by the mobile packet radio network. For the example embodiment 
the radio access facility is provided in accordance with the Universal Terrestrial Radio 
Access Network (UTRAN) system which is specified in accordance with the 3GPP 
standard. The SGSN is connected to the GGSN via a Gn interface if the SGSN is 
within the same Public Land Mobile Network (PLMN), and connected via the Gp 
interface to GGSNs belonging to other PLMNs. 

An SGSN provides mobility management ofUEs which are moving within an 
area supported by the mobile radio network. To this end the SGSN is provided with 
access to a Home Location Register (HLR) 1 10. The SGSN is arranged to route data 
packets to Radio Network Controllers (RNC) 1 12, 1 14 for communication via the 
UTRAN radio access facility to mobile users UE 116, 118. The UTRAN radio access 
facility is provided using Node B apparatus 120, 122, 124, 126, 128, which effectively 
form base stations providing radio coverage for the area served by the mobile 
telecommunications network. The interface 130, 132, 134, 136, 138 between each 
RNC 1 12, 1 14 and the Node B apparatus 120, 122, 124, 126, 128, are labelled Iub and 
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conform to an established or evolving standard. Similarly the interfaces 140, 142 
between the SGSN and each RNC 112, 114 are labelled as lu-ps and is an evolving 
standard. 
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CLAIMS 

1. An internet packet comprising a header field, the header field including 
a field identifying a source address of the internet packet, a field identifying the 
destination address of the internet packet and a next header field identifying whether 

5 an extension header follows the header and a type of the extension header, wherein the 
extension header indicates a hop-by-hop option header, the hop-by-hop extension 
header including a router alert option header indicating that the extension field is 
optional for a router to read, and a field providing information for a gateway support 
node of a packet radio network. 

10 

2. An internet packet as claimed in Claim 1, wherein the field providing 
information for the gateway support node includes a home address of a mobile node. 

3. An internet packet as claimed in Claim 1 or 2, wherein the router alert 
15 option header includes a first field indicating that the hop-by-hop extension header is 

optional, a second field indicating the hop-by-hop option type number, and a third 
value field, the value in the value field indicating that a fourth field provides the 
information for the gateway support node. 

20 4. An internet packet as claimed in any preceding claim, wherein the first 

field of the router alert option header is provided as a relatively short field with the 
effect that a time for a router to read the first field is reduced with respect to a 
requirement to read all data in the hop-by-hop extension header. 

25 5. An internet packet as claimed in Claim 4, wherein the first field 

comprises three bits. 

6. An internet packet as claimed in Claim 5, wherein the three bits are all 

zeros. 

30 
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7 An internet packet as claimed in Claims 4 to 6, wherein the second field 
of the router alert option header indicating the hop-by-hop option type comprises five 
bits set to a value of five. 

5 8. An internet packet as claimed in any preceding Claim, wherein the 

internet packet is a Ipv6 internet packet. 

9 An internet packet as claimed in any of Claim 2 to 8, wherein the home 
address of the mobile node corresponds to the source address of the mobile node when 
it) associated with a home network when an internet protocol session was uutiated. 

10 An internet packet as claimed in any of Claims 2 to 8, wherein the 
home address of the mobile node corresponds to the destination address of the mobfie 
node associated with a home network when an internet protocol session was nuuated. 

11 An internet packet as claimed in any of Claims 1 to 10, wherein the the 
packet radio network is a General Packet Radio Service network, the information for 
the gateway support node being provided for a Gateway GPRS Support Node of the 
GPRS network. 
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12 A gateway support node (GGSN) operable to provide an interface 
between an external packet data communications network and a packet radio network, 
the gateway support node (GGSN) being operable upon receipt of the internet packet 

according to any of claims 1 to 1 1 , 

to detect that a next header field of the internet packet includes a hop-by-hop 

field option, and , 

to recover information for the gateway support node, from the field prodded m 
the hop-by-hop extension header field providing data representing the information and 
to control egress and/or ingress of internet packets to the packet radio network m 
30 accordance with the information. 
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13. A gateway support node as claimed in Claim 12, wherein the packet 
radio network provides a plurality of packet data bearers for communicating the 
internet packets with nodes attached to the packet radio network, each of the packet 
data bearers being defined with respect to a source home address of nodes 
communicating the internet packets, the gateway support node being operable 

to control ingress of internet packets from the external communications 
network to the packet data bearers of the packet radio network, by 

detecting from the data provided in the hop-by-hop extension header field for 
the gateway support node a source home address of a mobile correspondent node 
communicating the internet packets, the home address being used by the gateway 
support node to identify the packet data bearer for communicating the internet packets 
to a correspondent node attached to the packet radio network, and 

allowing ingress of the internet packets to the identified packet data bearer. 

14. A gateway support node as claimed in Claim 13, the gateway support 
node being operable 

to allow ingress of the internet packets if either the address in the source 
address field of the internet packet or the address provided in the field in hop-by-hop 
extension header for the gateway support node corresponds to a packet data bearer. 

15. A gateway support node as claimed in Claim 13 or 14, the gateway 
support node being operable 

to perform egress packet filtering in accordance with a destination address of 
internet packets received from the plurality of packet data bearers, egress of internet 
packets being allowed for internet packets having a legitimate destination address, and 
upon receipt of the internet packet according to any of Claims 1 to 10, 

to detect from the data provided in the hop-by-hop extension header field for 
the gateway support node a destination home address of a mobile correspondent node 
which is to be the destination of the internet packets, and 

to allow egress of internet packets if the gateway support node recognises the 
destination home address as a legitimate home address. 
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16. A gateway support node as claimed in Claim 15, the gateway support 
node being operable to allow egress of the internet packets if either the address in the 
destination address field of Ihe packet or the address provided in the hop-by-hop 
extension header for the gateway support node is a legitimate destination address. 

5 

17. A gateway support node as claimed in any of Claims 12 to 16, wherein 
the gateway support node is operable as a Gateway GPRS Support Node (GGSN), 
according to the General Packet Radio System standard. 

10 18. A packet radio network operable to communicate internet packets 

between an external packet data network and nodes associated with the packet radio 
network, the packet radio network providing a plurality of packet data bearers for 
communicating the internet packets to and/or from the nodes attached to the packet 
radio network, the packet radio network including a gateway support node as claimed 

15 in any of Claims 12 to 17. 

19. A packet radio network as claimed in Claim 18, wherein the packet 
radio network is operable in accordance with the General Packet Radio System 
(GPRS) standard, the gateway support node being a Gateway GPRS Support Node 

20 (GGSN). 

20. An internet packet router operable to receive an internet packet 
according to any of Claims 1 to 1 1, the router being operable 

to detect that a next header field of the internet packet includes a hop-by-hop 
25 field option, 

to identify a router alert header type within the hop-by-hop extension header 
field, and 

not to read further the content of the hop-by-hop extension field. 



30 



21 . A method of operating a gateway support node to interface between an 
external packet data communications network and a packet radio network, the method 
comprising 
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receiving an internet packet according to any of claims 1 to 1 1, 
detecting that a next header field of the internet packet includes a hop-by-hop 
field option, and 

recovering information for the gateway support node, from the field provided 
5 in the hop-by-hop extension header field providing data representing the information, 
and 

controlling egress and/or ingress of internet packets to the packet radio network 
in accordance with the information. 

10 22. A method as claimed in Claim 21, wherein the packet radio network 

provides a plurality of packet data bearers for communicating the internet packets with 
nodes attached to the packet radio network, each of the packet data bearers being 
defined with respect to a source home address of nodes communicating the internet 
packets, the controlling the ingress of internet packets from the external 

15 communications network to the packet data bearers of the packet radio network, 
comprising 

detecting from the data provided in the hop-by-hop extension header field for 
the gateway support node a source home address of a mobile correspondent node 
communicating the internet packets, the home address being used by the gateway 
20 support node to identify the packet data bearer for communicating the internet packets 
to a correspondent node attached to the packet radio network, 

allowing ingress of the internet packets to the identified packet data bearer, and 
otherwise dropping the internet packet. 

25 23. A method as claimed in Claim 21 or 22, the method comprising 

performing egress packet filtering in accordance with a destination address of 
internet packets received from the plurality of packet data bearers, egress of internet 
packets being allowed for internet packets having a legitimate destination address, and 
upon receipt of the internet packet according to any of Claims 1 to 1 1, 

30 detecting from the data provided in the hop-by-hop extension header field for 

the gateway support node a destination home address of a mobile correspondent node 
which is to be the destination of the internet packets, and 
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allowing egress of internet packers if the gateway support node recugmses the 
destination home address as a legWhnate home addreaa. 

24. Asignalrenresentinganrntemetpaeketaecordrngmanyofclahnslm 

5 n. 

25 . A signal baring medium, the medium bearing the signal according «o 
Claim 24. 

10 26 Use of an IPv6 Router Alert option header for communicating 

information relating to mobility to a Gateway GPRS Support Node. 

27 A computer program providing computer executable instructions, 
which when loaded on to a date processor configures fire data processor ,0 operate as a 

15 gateway support node as claimed in any of Claims 12 to 17. 

28 A computer program having computer executable instiuetions, which 
when loaded on to a data processor causes tire date processor ,o perform a method 
according to any of Claims 22 to 24. 
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29 A computer program product having a computer readable medium 
having recorded thereon information signals representative of the computer program 
claimed in Claim 27 or 28. 

25 30. A packet radio network or a gateway support node as claimed as herein 

before described with reference to the accompanying drawings. 

31 . A method substantially as herein before described with reference to the 
accompanying drawings. 
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ABSTRACT 

PACKET DATA COMMUNICATIONS 

An internet packet comprises a header field, the header field including a field 
identifying a source address of the internet packet, a field identifying the destination 
5 address of the internet packet and a next header field identifying whether an extension 
header follows the header and a type of the extension header. The extension header 
indicates a hop-by-hop option header, the hop-by-hop extension header including a 
router alert option header type indicating that the extension field is optional for a 
router to read, and a field providing information for a gateway support node of a 

10 packet radio system network. A gateway support node is thereby provided with 
information, which may be required for example to support A mobile internet protocol 
(IP). However, by providing the router alert option field, a router is not required to 
read the remainder of the hop-by-hop option field. As a result, a reduction in the 
performance of the router in routing internet packets, which may have been incurred if 

15 the router was required to read all the hop-by-hop extension field can be limited. 



Figure 6 



Ol7$78<f6 



>/?o 




1 



WE 





/2Z I%£fe 




*-2ca 



2//0 




1 



UP-LltiK imeMZT PACKET (CAJ-*HA>) 
D&JwmzM 30UH.cE Htf'bV-t»P 



ZfO 




3 



5//o 




Version 


601 


Traffic Class 


602 


Flow Label 


604 


Payload Length 606 


Next Header 610 
Hop-by-hop option ="0" 


Hop Limit 


608 


Source Addre 
61?. 


!SS 


Destination Ac 
614 


Idress 


Next 
Header 

616 


Header 
Extension 
Length 
620 


Router 
Alert . 

Value = "0" • 
622 


Hop-by-hop 
option type, 
Value = "5" 
624 


Value = "2" or "3" 
For GGSN Mobility 


626 


Source/Destination Home Address of Mobile Node 




628 



%SAJ rece f v€S> 4/? packet f^wn 



the ayte^/iccc nef^orK 




r & .7 



7//o 



S7 




flrop tin t/rtesnet pa.c^C 




Kooubzr recedes / x /i&r/u>£ /x&l/cc£ ^$2-° 



No 



Y? 5 oz, 



acts pa daM cm tli ko^ty-Aof e#6esu/d/i /ec&fe^ 



fa odes d&es /w£ read &i o/7 Atous&i^ 



530 



lo//o 



T 




A lSU 




r 



535 



S&lP /tone fids? 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 



□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 



/ 




LINES OR MARKS ON ORIGINAL DOCUMENT 



